Commercial webpages include code that makes web server requests specifically for the purpose of recording marketing and user interaction events for subsequent analysis. Commonly referred to as a tracking tag, this code is interpreted by a user's web browser as part of the instruction set for rendering and controlling the behavior of a webpage.
Examples of the data analysis made possible by tracking tags include, but are not limited to: the geographic location of the user, the number of times a webpage has been viewed by a unique user, the links on a page that a user has clicked, the ads that were included on a page, whether the user accessed a page in response to an ad or marketing campaign, and how much money a user spent on a website after responding to a particular campaign.
Website owners may add tracking tags by appending them to the HTML source code of each webpage of their website. Tracking tags also may be included within content on a page that is linked from third-party content providers—for example, ads, video players, news feeds, and blogs. Tracking tags may send data to the website owner's servers or to third-party servers, and this data may be used for the benefit of the website owner, advertisers, advertising and marketing agencies, data aggregators, data analysis services, and other parties. The parties that receive such data are referred to generally as “data receivers.”
Tracking tags are implemented in a number of ways, the most common of which are HTML anchor or iframe tags that request a file from a web server and JavaScript statements that post data to a web server of an intended data receiver party. The response from the web server often sets a browser cookie with data that is used to anonymously identify a particular user on subsequent requests. Typically, data analysis products and services provide these tracking tags, often in the form of HTML tags or JavaScript statements, to website owners and third-party content providers, who must then copy the tracking tag code into the HTML source code for the webpage or linked content item that is to be tracked.
Tracking tags may collect data elements implicitly or explicitly. Implicit data collection occurs when a tracking tag passes data elements that can be extracted deterministically from site/application context without custom data integration code. Data collected implicitly are referred to as “implicit data elements.” Examples of implicit data elements include without limitation: (1) HTTP request headers, such as the URL of the object requested, the user's IP address, user-agent, language, referring URL, and cookie values; (2) client object values and events, such as those defined by the World Wide Web Consortium Document Object Model (DOM) and application development frameworks such as Adobe Flash, Apple iOS, Google Android, Facebook API, etc.; and (3) “well-known content,” such as document title, unparsed document body, and other document elements that can be inferred through commonly used markup identifiers such as page description, keywords, headings, images, etc.
Data collected explicitly are referred to as “explicit data elements.” The word “explicit” indicates that the data element has been explicitly defined by a data producer. Unlike implicit data elements, explicit data elements cannot be extracted deterministically from the site/application without custom data integration code. Explicit data elements vary greatly based on request context. Examples of explicit data elements include without limitation: (1) machine-interpreted variables and expressions, such as those used by JavaScript when rendering a webpage or Adobe ActionScript when running a Flash application; (2) arbitrary structured data, such as URL query string parameters and “meta” tags, and similar key/value pairs where the structure and content are defined entirely by the site/application; (3) arbitrary unstructured content, which must be parsed or otherwise derived from a document body or subsection thereof.
Explicit data elements are enumerated in website/application markup and/or in the request context—either as variables/expressions, arbitrary structured data, or arbitrary unstructured content. Mechanisms for enumerating data elements include, but are not limited to, URL query string parameters, HTML meta tag values, JavaScript variables, and unstructured content, examples of which are shown in FIG. 1.
Because explicit data collection requires site/application owners to write custom data integration code, maintaining tracking tags for multiple parties is cumbersome and can create technical issues. Though each tracking tag uniquely encodes explicit data based on the interface specification of its data collection servers, essentially the same data elements and values are passed to multiple parties. Because marketing and user behavioral data products and services base their analysis on the same superset of interaction events, their tracking tags collect nearly identical data elements. The differences between these otherwise redundant tracking tags can be characterized as implementation details, such as parameter and variable names, value assignments and the particular subset of interaction events that is relevant to the analysis product or service.
A few of the technical and commercial inefficiencies introduced by the proliferation of tracking tags are listed below.
(1) Multiple tracking tags make webpages more complex to implement and debug because each tracking tag's code must be checked for syntax and logic errors, each webpage must be tested to ensure correct functionality after a tracking tag has been incorporated into the source code, and code changes from tracking tag providers must be integrated into webpages on a regular basis.
(2) Because tracking tags must be interpreted by a user's web browser or other user agent, each tracking tag adds to the amount of time that it takes to download a page and execute its HTML and JavaScript code. Processing multiple tracking tags may materially impair site performance.
(3) If a user's web browser cannot contact the particular web servers requested by a tracking tag, then a webpage may not load correctly. As more tracking tags are added to a webpage, the possibility for load errors increases.
(4) If a user exits a webpage before all tracking tags finish loading, then some parties will not receive a complete set of data from that user. Incomplete data impacts the quality of data analysis products, skews marketing campaign performance reports and impacts payments based on commercial terms related to campaign performance measurements.
(5) The removal of tracking tags from a website also introduces complexity and requires effort to debug. Because of this, website administrators may not remove tracking tags in a timely manner after terminating relationships with a data receiver. This potentially provides a terminated data receiver with unlicensed access to marketing and user behavioral data, and unnecessarily adds to the performance problems caused by multiple tracking tags.
(6) Tracking tags are used to attribute the source of conversion events such as purchases and user registrations to a particular marketing campaign. This attribution is the basis for commercial terms that specify a cost-per-acquisition (CPA) payment schedule. Websites often operate a number of CPA campaigns with different marketing partners, and each partner provides its own tracking tag. Because a user may have engaged several marketing partners leading up to a conversion event, multiple parties may claim attribution for the event. Commercial agreements between websites and marketing partners specify a methodology for determining which party gets paid when multiple attributions exist—for example, the last campaign that influenced the conversion event is commonly the only one entitled to payment. In practice, however, websites often pay all parties that contributed to a conversion event because there is no effective way to enforce contractual attribution methodologies. Multiple tracking tags are among the root causes for redundant payments because each party is collecting its own data without a commonly accepted way to reconcile conflicting attribution.
Thus, there is a pressing need to facilitate data collection by multiple parties without implementing multiple tracking tags. A method is needed to reduce the redundant data collection that executes within a web browser, while still providing each party a complete set of data. Methods exist to aggregate tracking tags from multiple parties into a single concatenated HTML or JavaScript code block, often referred to as “piggybacking” These “piggybacking” methods do not mitigate any of the inefficiencies listed above because each party's tracking tag code still must be executed by the user's web browser. What is needed instead of “piggybacking” is a method to collect data within the user's web browser only once, then to distribute the data to those parties that are entitled to receive it.
A solution is also needed to address consumer privacy. Data producers, such as website operators, advertisers, and third-party content providers distributing information to consumers, collect and use data about a consumer to direct many actions including content personalization, aggregating feedback for improvement, processing transactions, administering promotions, or distributing marketing emails. A data producer's right to collect data for its own use is typically communicated to the consumer by a “terms of service” agreement or similar document made available to the consumer. When consumers interact with content published by data producers, they are typically identified by a data producer's cookie stored within the consumer's web browser.
The concept of “opt-out” refers to methods by which consumers can avoid data collection as a declared election. This is typically accomplished via a webpage provided by the data producers or data receivers that allows the consumer to indicate their intent to opt-out, effectively disconnecting the consumer's browser cookie from further data collection. An opt-out policy infers that data collection is by default valid for consumers that have not explicitly opted-out.
From a technical perspective, opt-out enforcement results in the affected data producer or data receiver writing the consumer's opt-out intent to a cookie they can access. Awareness of this cookie gives the data producer or data receiver the means to ensure that data is not collected according to the opt-out policy.
The concept of “opt-in” refers to methods by which consumers can express permission to allow a data producer or data receiver to collect or use data. An opt-in policy infers that data collection by data producers or data receivers against consumers is by default invalid.
Inefficiencies and problems are introduced with the current landscape of enforcement of privacy and data collection policies. While data producers own the creation of all the content on which data is collected, they do not own the process of data collection by the data receivers. Data producers lack an effective way to respond to the consumer's preferences regarding data collection. As an example, if the consumer specifies a preference that their data should not be collected for targeted advertising purposes—managed by particular data receivers—a data producer which has integrated the data receiver's tags has no ability to stop the data collection. Data producers also lack the ability to take action against a consumer's privacy preferences. Data producers lack technology which allows them to offer and enforce privacy rights management on a site-specific level—where consumers declare their privacy preferences on the data producer's site—as well as a network-wide level where consumers declare their privacy preferences as general rules for the content they consume across the internet.
Thus what is also needed is a system and method of enforcement of privacy and data collection policy that allows data producers to support a consumer's privacy rights on a site-wide or network-wide basis.